System and method for content protection based on a combination of a user pin and a device specific identifier

ABSTRACT

Disclosed herein are systems, methods, and non-transitory computer-readable storage media for encryption and key management. The method includes encrypting each file on a computing device with a unique file encryption key, encrypting each unique file encryption key with a corresponding class encryption key, and encrypting each class encryption key with an additional encryption key. Further disclosed are systems, methods, and non-transitory computer-readable storage media for encrypting a credential key chain. The method includes encrypting each credential on a computing device with a unique credential encryption key, encrypting each unique credential encryption key with a corresponding credential class encryption key, and encrypting each class encryption key with an additional encryption key. Additionally, a method of generating a cryptographic key based on a user-entered password and a device-specific identifier secret utilizing an encryption algorithm is disclosed.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/299,375, filed Jun. 9, 2014, entitled “SYSTEM AND METHOD FOR CONTENTPROTECTION BASED ON A COMBINATION OF A USER PIN AND A DEVICE SPECIFICIDENTIFIER, which is a continuation of U.S. patent application Ser. No.12/797,587, filed Jun. 9, 2010, entitled “SYSTEM AND METHOD FOR CONTENTPROTECTION BASED ON A COMBINATION OF A USER PIN AND A DEVICE SPECIFICIDENTIFIER,” now U.S. Pat. No. 8,788,842, which is acontinuation-in-part (CIP) of U.S. patent application Ser. No.12/756,153, filed on Apr. 7, 2010, entitled “SYSTEM AND METHOD FORFILE-LEVEL DATA PROTECTION,” now U.S. Pat. No. 8,510,552, each of whichare herein incorporated by reference in their entirety.

BACKGROUND

1. Technical Field

The present disclosure relates to data protection and more specificallyto combining a user PIN with a unique, device-specific identifier.

2. Introduction

As more and more individuals and enterprises rely on smartphones andother mobile devices storing confidential or sensitive information,security is an increasing concern. Because such mobile devices are usedas communication centers, they frequently contain sensitive informationsuch as contact information, call logs, emails, pictures, and so forth,of high potential value and/or sensitivity. In certain applications,protecting this information is desirable. In some applications,encryption is used to protect sensitive information.

Encryption is the process of transforming a message into ciphertext thatcannot be understood by unintended recipients. A message is encryptedwith an encryption algorithm and encryption key. Decryption is theprocess of transforming ciphertext back to the message in a readable orunderstandable form.

In many cases, users select short personal identification numbers (PINs)or passwords which an attacker can easily compromise with a brute forceattack running on a modestly powerful computer or group of computers.However, users are often reluctant to select a longer password becauselonger passwords are more difficult to remember, or users are unable toselect a longer password because the system limits the password length.What is needed in the art is an improved approach for protecting contentbased on a user password.

SUMMARY

Additional features and advantages of the disclosure will be set forthin the description which follows, and in part will be obvious from thedescription, or can be learned by practice of the herein disclosedprinciples. The features and advantages of the disclosure can berealized and obtained by means of the instruments and combinationsparticularly pointed out in the appended claims. These and otherfeatures of the disclosure will become more fully apparent from thefollowing description and appended claims, or can be learned by thepractice of the principles set forth herein.

Disclosed are systems, methods, and non-transitory computer-readablestorage media for file-level data protection, specifically encryptionand key management. A system practicing the method encrypts each filewith a unique file encryption key, encrypts each file encryption keywith a class encryption key, and encrypts each class encryption key withan additional encryption key.

In one embodiment, the system encrypts a credential keychain. Acredential keychain can be a database or files that store credentials.The system encrypts at least a subset of credentials with a uniquecredential encryption key, encrypts each unique credential encryptionkey with a class encryption key and encrypts each credential classencryption key with an additional encryption key.

The system assigns each respective file or credential to one of a set ofprotection classes, and assigns each protection class a class encryptionkey. The protection classes allow for certain file behavior and accessrights, such as write-only access, read/write access, and read-only, nowrite access. The system encrypts the class encryption key based on acombination of one or more of a user passcode, a public encryption keyand a unique device specific code.

In a second embodiment, the system verifies a password. A systempracticing the method decrypts a key bag containing encryption keys witha user entered password. Each encryption key in the key bag isassociated with a protection class on a device having file-level dataprotection. The system retrieves data from one or more encrypted filesusing a class encryption key from the decrypted key bag. Then the systemverifies the entered password based on a comparison of the retrieveddata with expected data.

In a third embodiment, the system generates a cryptographic key based ona device-specific identifier. A system practicing the method receives auser-entered passcode on a device and combines the passcode with anon-extractable secret associated with the device to yield a derivedmaster key. The system generates the master key according to anencryption algorithm. Then the system encrypts content on the devicewith the derived key.

A mobile, stationary, or combination of multiple computing devices canpractice the principles disclosed herein. Other applications andcombinations of the principles disclosed herein also exist, for exampleprotecting system data based on file-level data protection.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the disclosure can be obtained, a moreparticular description of the principles briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only exemplary embodiments of the disclosure and are nottherefore to be considered to be limiting of its scope, the principlesherein are described and explained with additional specificity anddetail through the use of the accompanying drawings in which:

FIG. 1 illustrates an example system embodiment;

FIG. 2 illustrates an example of asymmetric key cryptography;

FIG. 3 illustrates an example of symmetric key cryptography;

FIG. 4 illustrates an exemplary file-level data protection methodembodiment;

FIG. 5 illustrates an exemplary credential keychain protection methodembodiment;

FIG. 6 illustrates an exemplary file system encrypted on a per filebasis using class keys;

FIG. 7 illustrates an exemplary set of key bags;

FIG. 8 illustrates a first exemplary backup initiation method embodimentfor a host device;

FIG. 9 illustrates a second exemplary backup initiation methodembodiment for a client device;

FIG. 10 illustrates an exemplary backup initiation system configuration;

FIG. 11 illustrates an example backup ticket;

FIG. 12 illustrates a first exemplary backup method embodiment for aclient device;

FIG. 13 illustrates a second exemplary backup method embodiment for ahost device;

FIG. 14 illustrates an exemplary backup system configuration;

FIG. 15 illustrates a first exemplary encrypted backup file restorationmethod embodiment for a host device;

FIG. 16 illustrates a second exemplary encrypted backup file restorationmethod embodiment for a client device;

FIG. 17 illustrates an exemplary encrypted backup file restoration filesystem configuration;

FIG. 18 illustrates a first exemplary data synchronizationinitialization method embodiment for a host device;

FIG. 19 illustrates a second exemplary data synchronizationinitialization method embodiment for a client device;

FIG. 20 illustrates an example sync ticket;

FIG. 21 illustrates an exemplary data synchronization initializationsystem configuration;

FIG. 22 illustrates a first exemplary data synchronization methodembodiment for a host device;

FIG. 23 illustrates a second exemplary data synchronization methodembodiment for a client device;

FIG. 24 illustrates an exemplary obliteration method embodiment;

FIG. 25 illustrates an exemplary password verification methodembodiment;

FIG. 26 illustrates an example PBKDF2 using HMAC-SHA1 embodiment;

FIG. 27 illustrates an example key derivation embodiment;

FIG. 28 illustrates an example device-specific based key generationsystem embodiment;

FIG. 29 illustrates an exemplary device-specific based key generationmethod embodiment;

FIG. 30 illustrates an exemplary method embodiment for generating aderived key from a user passcode and a device-specific secret;

FIG. 31 illustrates a first exemplary algorithm for calculating an AESkey from a user password; and

FIG. 32 illustrates a second exemplary algorithm for calculating an AESkey from a user password.

DETAILED DESCRIPTION

Various embodiments of the disclosure are discussed in detail below.While specific implementations are discussed, it should be understoodthat this is done for illustration purposes only. A person skilled inthe relevant art will recognize that other components and configurationsmay be used without parting from the spirit and scope of the disclosure.

The present disclosure addresses the need in the art for improvedencryption approaches. The encryption approaches herein are based on aper-file and per-class encryption or data protection scheme. A briefintroductory description with reference to these approaches will beprovided, followed by a discussion of a basic, general-purpose system orcomputing device in FIG. 1 which can be employed to practice all or partof the concepts described herein. A more detailed description of themethods and encryption approaches will then follow.

The data protection features disclosed herein can safeguard user data inthe event of a stolen device. Current encryption schemes encrypt alldata stored on a device with a single symmetric encryption key that isavailable when the system is running. Thus, if the device is crackedsuch that the attacker can run his own code on the device, the user'sdata is accessible to the attacker.

In one aspect, the approaches set forth herein rely on data encryptedwith a secret known only to the user to protect the user's data, such asa passcode. As a result, if the user has enabled data protection but hasnot entered his passcode since a device reboot, his data will not beaccessible to the system. However, this approach introduces a number ofcomplications, mostly surrounding processes that access user data in thebackground, even while the device is locked, such as email and calendarinformation. Furthermore, this same set of data is necessary to properlybackup, sync and potentially restore the user's data.

In one aspect where the system encrypts all new files on a file system,the data protection feature relies on every file on the data partitionbeing individually encrypted with a unique symmetric encryption key.This encryption mechanism can supplant existing hardware encryptionfeatures by taking advantage of the hardware acceleration in the kernelwithout significant performance degradation. The system uses AES indirect memory access (DMA) so that a memory-to-memory encryptionoperation is not needed. However, the principles disclosed herein can beperformed by a general purpose processor executing appropriateencryption instructions, a special purpose processor designed to performencryption-based calculations, or a combination thereof.

The system can generate a random 256-bit AES key (or other size or typeof key) to associate with a file when the file is created. An AES key isa cryptographic key used to perform encryption and decryption using theAdvanced Encryption Standard algorithm. All input and output (I/O)operations performed on that file use that AES key so that the raw filedata is only written to the file system in encrypted form. Thisindividual file key accompanies the file as metadata, so that the fileand key can be backed up and restored without having to access the filecontents. The system can tell if a passcode is in compliance based onthe metadata even when the passcode is not stored directly. This featurecan be useful, for example, when testing passcode compliance with anylocal and/or server restrictions on the passcode strength such as anExchange server password policy.

In one variation, the system defines a new mount option to be used fordevices that support content encryption. This mount option instructs thekernel that all new files created on the partition should not beencrypted by default. This option can be used for system partitions, asthose files do not need to be encrypted, as well as data partitions forolder devices that do not support data protection.

When restoring backed up data to a device, a restore daemon can look fora new option in the device tree that indicates the device does notsupport data protection. In one implementation, the restore daemon isresponsible for laying down the fstab file on the system partitionat/private/etc/fstab. The fstab file can contain at least two entries.The first entry instructs the kernel to mount the system partition as aread only volume. The second entry instructs the kernel to mount thedata partition at/private/var as a writable volume with the new dataprotection option. In another implementation, instead of using a newmount option that must explicitly be set in the fstab file, aHierarchical File System (HFS) option is added in the header. Themounter auto detects that data protection should be turned on.

When a user enters a password, the system uses the entered password toderive a key which is used to decrypt the class keys. Alternatively, thesystem can derive a key from any user controlled source, such as adongle. A dongle is a small piece of hardware that connects to a device.Each class key is wrapped with integrity, which allows the system todetermine whether the unwrapping proceeded correctly. If the systemunwraps all keys correctly, the system accepts the password. In oneaspect, the system tries to decrypt all keys to maximize the time spentdecrypting.

These and other variations shall be discussed herein as the variousembodiments are set forth. The disclosure now turns to FIG. 1.

With reference to FIG. 1, an exemplary system includes a general-purposecomputing device 100, including a processing unit (CPU or processor) 120and a system bus 110 that couples various system components includingthe system memory 130 such as read only memory (ROM) 140 and randomaccess memory (RAM) 150 to the processor 120. The system 100 can includea cache 122 of high speed memory connected directly with, in closeproximity to, or integrated as part of the processor 120. The system 100copies data from the memory 130 and/or the storage device 160 to thecache 122 for quick access by the processor 120. In this way, the cache122 provides a performance boost that avoids processor 120 delays whilewaiting for data. These and other modules can be configured to controlthe processor 120 to perform various actions. Other system memory 130may be available for use as well. The memory 130 can include multipledifferent types of memory with different performance characteristics. Itcan be appreciated that the disclosure may operate on a computing device100 with more than one processor 120 or on a group or cluster ofcomputing devices networked together to provide greater processingcapability. The processor 120 can include any general purpose processorand a hardware module or software module, such as module 1 162, module 2164, and module 3 166 stored in storage device 160, configured tocontrol the processor 120 as well as a special-purpose processor wheresoftware instructions are incorporated into the actual processor design.The processor 120 may essentially be a completely self-containedcomputing system, containing multiple cores or processors, a bus, memorycontroller, cache, etc. A multi-core processor may be symmetric orasymmetric.

The system bus 110 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. A basicinput/output (BIOS) stored in ROM 140 or the like, may provide the basicroutine that helps to transfer information between elements within thecomputing device 100, such as during start-up. The computing device 100further includes storage devices 160 such as a hard disk drive, amagnetic disk drive, an optical disk drive, tape drive or the like. Thestorage device 160 can include software modules 162, 164, 166 forcontrolling the processor 120. Other hardware or software modules arecontemplated. The storage device 160 is connected to the system bus 110by a drive interface. The drives and the associated computer readablestorage media provide nonvolatile storage of computer readableinstructions, data structures, program modules and other data for thecomputing device 100. In one aspect, a hardware module that performs aparticular function includes the software component stored in a tangibleand/or intangible computer-readable medium in connection with thenecessary hardware components, such as the processor 120, bus 110,output device 170, and so forth, to carry out the function. The basiccomponents are known to those of skill in the art and appropriatevariations are contemplated depending on the type of device, such aswhether the computing device 100 is a small, handheld computing device,a desktop computer, or a computer server.

Although the exemplary embodiment described herein employs flash memorystorage 160, it should be appreciated by those skilled in the art thatother types of computer readable media which can store data that areaccessible by a computer, such as a hard disk drive, magnetic cassettes,flash memory, digital versatile disks, cartridges, random accessmemories (RAMs) 150, read only memory (ROM) 140, a cable or wirelesssignal containing a bit stream and the like, may also be used in theexemplary operating environment. Tangible computer-readable storagemedia expressly exclude media such as energy, carrier signals,electromagnetic waves, and signals per se.

To enable user interaction with the computing device 100, an inputdevice 190 represents any number of input mechanisms, such as amicrophone for speech, a touch-sensitive screen for gesture or graphicalinput, keyboard, mouse, motion input, speech and so forth. An outputdevice 170 can also be one or more of a number of output mechanismsknown to those of skill in the art. In some instances, multimodalsystems enable a user to provide multiple types of input to communicatewith the computing device 100. The communications interface 180generally governs and manages the user input and system output. There isno restriction on operating on any particular hardware arrangement andtherefore the basic features here may easily be substituted for improvedhardware or firmware arrangements as they are developed.

For clarity of explanation, the illustrative system embodiment ispresented as including individual functional blocks including functionalblocks labeled as a “processor” or processor 120. The functions theseblocks represent may be provided through the use of either shared ordedicated hardware, including, but not limited to, hardware capable ofexecuting software and hardware, such as a processor 120, that ispurpose-built to operate as an equivalent to software executing on ageneral purpose processor. For example the functions of one or moreprocessors presented in FIG. 1 may be provided by a single sharedprocessor or multiple processors. (Use of the term “processor” shouldnot be construed to refer exclusively to hardware capable of executingsoftware.) Illustrative embodiments may include microprocessor and/ordigital signal processor (DSP) hardware, read-only memory (ROM) 140 forstoring software performing the operations discussed below, and randomaccess memory (RAM) 150 for storing results. Very large scaleintegration (VLSI) hardware embodiments, as well as custom VLSIcircuitry in combination with a general purpose DSP circuit, may also beprovided.

The logical operations of the various embodiments are implemented as: 1)a sequence of computer implemented steps, operations, or proceduresrunning on a programmable circuit within a general use computer, 2) asequence of computer implemented steps, operations, or proceduresrunning on a specific-use programmable circuit; and/or 3) interconnectedmachine modules or program engines within the programmable circuits. Thesystem 100 shown in FIG. 1 can practice all or part of the recitedmethods, can be a part of the recited systems, and/or can operateaccording to instructions in the recited tangible computer-readablestorage media. Such logical operations can be implemented as modulesconfigured to control the processor 120 to perform particular functionsaccording to the programming of the module. For example, FIG. 1illustrates three modules Mod1 162, Mod2 164 and Mod3 166 which aremodules configured to control the processor 120. These modules may bestored on the storage device 160 and loaded into RAM 150 or memory 130at runtime or may be stored as would be known in the art in othercomputer-readable memory locations.

Having disclosed an exemplary computing system, the disclosure now turnsto a brief discussion of public-key cryptography. Public-keycryptography is a cryptographic approach that utilizes asymmetric keyalgorithms in addition to or in place of traditional symmetric keyalgorithms. FIG. 2 illustrates asymmetric key cryptography and FIG. 3illustrates symmetric key cryptography. Asymmetric key algorithms differfrom symmetric key algorithms in that different keys are used forencryption 210 and decryption 220. Symmetric key algorithms use the samekey for encryption 310 and decryption 320 and are based on the notion ofa shared secret key between the sender and the receiver of a message.Because public-key cryptography utilizes different keys for encryptionand decryption, no secure exchange of a secret key between the senderand the receiver is needed.

In public-key cryptography, a mathematically related key pair isgenerated, a private key and a public key. Although the keys arerelated, it is impractical to derive one key based on the other. Theprivate key is kept secret and the public key is published. A senderencrypts a message with the receiver's public key 230, and the receiverof the message decrypts it with the private key 240. Only the receiver'sprivate key can decrypt the encrypted message.

Having disclosed some basic encryption-related concepts and systemcomponents, the disclosure now turns to the exemplary method embodimentshown in FIG. 4. For the sake of clarity, the method is discussed interms of an exemplary system 100 such as is shown in FIG. 1 configuredto practice the method.

FIG. 4 illustrates an exemplary file-level data protection methodembodiment. The system 100 encrypts each file in a file system with aunique file encryption key (410), encrypts each file encryption key witha class encryption key (420), and encrypts each class encryption keywith an additional encryption key (430). In one aspect, the classencryption key corresponds to the assigned protection class of the file.The protection class can allow for certain file behavior and accessrights.

Once each file is encrypted with its own unique key, the system 100 canprotect each one of those files with a secret known only to the user.When a file is created and individual file encryption key is generated,the system 100 can wrap that key with a class key. The unique fileencryption key is metadata that the system 100 can store in thefilesystem or which can exist in user space. The kernel can then cachethe key during file access. By always encrypting a file and thenwrapping its file key with a class key, the system 100 avoids the costof encrypting every file already created when the user enables dataprotection. Instead, the system 100 simply encrypts the set of classkeys, which is a bound and relatively inexpensive computationaloperation. With data protection enabled, if the user has not entered hispasscode, then the class keys are not available. If the kernel cannotaccess the class keys, it cannot decrypt the individual file keys andthe raw file data is inaccessible to the system. The efficacy of thefeature now depends on how the class keys are managed.

When the device, such as a smartphone or personal computer, is locked,the system explicitly purges keys stored in memory as well as any dataprotected file contents stored in memory which should be inaccessiblewhen the device is locked. For example, the system 100 can purge keysassociated with protection classes A, B, C, but not class D when thedevice enters or is about to enter a locked state. The device can alsopurge or otherwise remove access to the contents of files stored inmemory which are associated with classes A, B, C.

For example, protection classes can provide different functionality fordifferent levels of authentication. The scenario set forth belowillustrates one example application of protection classes. When a devicethat has data protection enabled first boots, the user has not yetentered his passcode. Thus none of the files are accessible because theclass keys themselves are encrypted. Because the system relies onpreference and configuration files that live on the data partition, theclass keys must be decrypted before the files can be accessed. If thosefiles cannot be read, then certain mission critical components are notable to boot to the point where the user can enter his passcode. Onecompromise is to separate the types of files that are accessible whenthe device has first booted from files that should only be accessiblewhen the user has entered his passcode. The files can be separated intoprotection classes. Protection classes can include many aspects ofpolicy for transformation, such as readability, writeability,exportability, and so forth. Some classes are associated with specificuser actions, such as generating new keys without erasing the entiredevice when a user changes his or her password, for example.

One example protection class, known as Class A, is a basic class fordata protected files. When the device first boots, Class A files are notaccessible until the user enters his passcode. When the device islocked, these files become inaccessible. Some applications and/or systemservices may need to adapt to Class A because they cannot access theirfiles when the device is locked, even if the application or systemservice is running in the background.

Another example protection class, known as Class B, is a specializedclass for data protected files that require write access even when thedevice is locked. When the device first boots, Class B files are notaccessible until the user enters his passcode. When the device islocked, these files can only be written to and not read. One example usefor Class B files is for content downloaded while the device is locked,such as email messages, text messages, cached updates, a cache maildatabase for messages downloaded while the device is locked, and soforth. When the device is later unlocked, such files can be read. Forexample, when the device is later unlocked, the cache mail database canbe reconciled with the primary mail database.

Another example protection class, known as Class C, is a specializedclass for data protected files that require read/write access even whenthe device is locked. For example, when the device first boots, thesefiles are not accessible until the user enters his passcode. When thedevice is locked, these files are still accessible. Class C files can beused for databases that need to be accessible while the device islocked. Some other example uses for Class C include data that can alwaysbe read once the device has been unlocked once after boot, even if itlocks again, such as contacts and a calendar.

Yet another example protection class, known as Class D, is a defaultclass for data protected files. Class D files are accessible regardlessof whether the user has entered his passcode.

While four classes are discussed in detail herein, the number ofprotection classes can be more or less, such as 2 protection classes, 10protection classes, or more and can include protection classes grantingdifferent access rights and performing different sets of functionalitythan what is discussed herein. Several additional exemplary protectionclasses follow. For example, one protection class can be a specializedclass for files that are tied to a single device using the UID or keysderived from the UID and cannot be migrated to a second device. A secondexemplary protection class can be a specialized class associated with aspecific application. A third exemplary protection class can generatenew keys whenever an escape from previous escrow is needed without theneed to erase the whole device, for example a password change. Thesystem 100 can change a passcode for every generation of a system keyback, especially when blastable storage contains a key that wraps systemkey bags, such that former weak key bags (the original that has an emptypasscode) become inaccessible on a passcode change.

In one aspect, when the system 100 changes states, such as going fromlocked to unlocked or vice versa, the system 100 erases certain classkeys from memory. For example, if the device has been locked, it canerase the Class A key from memory and treat Class B as read only.

As operating systems are upgraded to use updated sets of classes havingnew keys and/or entirely new classes, the system 100 can store a newClass A key, for example. In this example, the system 100 uses the newClass A key for newly created files, while the system retains the olderClass A key for dealing with older files. This can provide a protectionclass aware migration path for updating class keys in the event thatthey are cracked or more efficient algorithms or hardware are developed.

With respect to keychain backup items, the system can consider twodimensions. The first consideration is classes Ak, Ck, Dk and the secondconsideration is whether or not the keychain item is protected with thedevice UID, and thus can not be transferred to other devices. If thekeychain is protected with the device UID, it can only be restored tothe same device it was backed up from. Those classes are known as Aku,Cku, Dku. The additional “u” state is used for backup protection toindicate if it can be transferred to a different device. For example, if“u”, than it can not be restored to a different device. The class (A, C,D) is used at runtime on the device the same, regardless of the “u”state. If the system includes additional classes, the second dimension(whether or not it is also wrapped with the UID and can or cannot berestored to a different device) would also apply to the additional keyclasses.

In one embodiment, the system 100 encrypts a credential keychain. FIG. 5illustrates a system performing credential keychain data protection. Acredential keychain is a file, set of files or database that containscredentials. A credential can include a password, username, orencryption key, for example. The system 100 encrypts at least a subsetof credentials with a unique credential encryption key (510), encryptseach unique credential encryption key with a class encryption key (520),and encrypts each class credential encryption key with an additionalencryption key (530). The class encryption key corresponds to theassigned protection class of the file, wherein the protection classallows certain file behavior and access rights. Credential protectionclasses can be based on all or part of the protection classes set forthabove.

FIG. 6 illustrates an exemplary file system using file-level dataprotection which encrypts on a per file and per class basis. It can alsoillustrate an exemplary credential keychain using data protection. Thesystem assigns each respective file or credential to one of a set ofprotection classes 610, and assigns each protection class a classencryption key. In one aspect, each class encryption key is unique. Thesystem encrypts each file encryption key with the corresponding classencryption key 620. For example, File 1 and File 5 are part ofprotection Class A, but have unique encryption keys. File 1 is encryptedwith Key 1, while File 5 is encrypted with key 5. Both key 1 and 5 areencrypted with key A. The protection classes allow certain file behaviorand access rights. This tiered approach to file or credential accessthrough protection classes allows the system to protect filesdifferently depending on the desired level of security.

The system 100 encrypts the class encryption keys based on a combinationof one or more of a user passcode, a public encryption key and a uniquedevice specific code depending on the type of key bag in which the keysare stored. Key bags are a set of keys accessible to the system, such asan operating system kernel. In one variation, each key bag encryptsindividual class keys in a unique way based, for example, on a uniquecombination of the user passcode, the public encryption key, and theunique device specific code. One key bag encrypts class keys based onthe user passcode and the unique device specific code, another key bagencrypts class keys based just on the unique device specific code, andyet another key bag encrypts class keys based on all three, for example.The system 100 stores class encryption keys in key bags, such as adefault key bag, a protected key bag, an escrow key bag, and a backupkey bag.

In one embodiment, the key bags are accessible in user space, but theircontents can only be accessed in kernel space by a special kernelextension. A daemon in user space can provide the kernel with the properkey bag and the information necessary to access its contents. Further,backup and sync components on the host generally need to coordinate withthe device in order to make data accessible while the device is locked.This coordination can be handled by a lockdown service agent thatproxies their requests to a management daemon, which in turn coordinateswith the kernel extension.

The system 100 uses the different key bags for different purposes. Forexample, the backup key bag and/or the escrow key bag can be used inbacking up a device or synchronizing devices. A default key bag canprotect the device in its initial state before a user enables dataprotection such as by creating a passcode. In one aspect, the backup keybag is never kept on the device. The backup key bag is part of thebackup, and is used to encrypt the files in the actual backup, not anyfiles on the device. When restoring to a device, the backup key bag issent over, so the restored files from the backup can be decrypted.

In another variation, the escrow key bag is kept on the device, but itcan't be used by the device without a secret that is only kept on thebackup host. The escrow key bag is used to access files/keychain itemson the device so they can be backed up, even if the device is lockedwhere they normally could not be accessed. The backup host can be acomputer, another mobile device, a server or collection of servers, aweb service, or just a drive. Such a drive, for example, can requiresome credential from the device to gain access, but once the device canaccess it, the backup is just stored on the drive which is not an activeagent.

Regardless of the type of backup device type, the backed up files do nothave to be encrypted with the same file keys as the ones on the device.In one embodiment, the backup device transfers the files as is (with thesame encryption), and encrypts the file keys themselves with the backupkey bag's class keys. In another embodiment, the files are actuallytranscrypted (converted from one encryption scheme or key to anotherencryption scheme or key) using a file key that is different anddistinct from the file key used on the device.

More feedback on backup (related to my last note) - sorry I am sendingmultiple notes, I'm not reading with whole thing at once, and wanted toget you the feedback as soon as I read each section.

FIG. 7 illustrates an exemplary set of key bags on a device withfile-level data protection. The default key bag 710 contains all classencryption keys encrypted by the unique device specific code. The uniquedevice specific code is the only key available to the hardware, whilekeys derived from the unique device specific code are available inmemory. The system 100 utilizes the default key bag on a device thatdoes not have data protection enabled. In one variation, the defaultstate of the device is to operate with data protection disabled; theuser must enable data protection. In one aspect, the user automaticallyenables data protection by creating a passcode. The system 100 uses thepasscode to protect the class encryption keys in the protected key bag.When a user changes his password, the key that protects system key bagsis changed. Key bags protected by the former password becomeinaccessible on a passcode change.

The protected key bag 720 contains all class encryption keys encryptedby the user key and the unique device specific code. The user key can bethe same as the user passcode or can be derived from the user passcode.The user key is an encryption key based on the user passcode. When theuser enables data protection, such as by creating a passcode, the system100 converts the user's passcode into a derived secret that can be usedto protect the protection class keys. A new key bag, the protected keybag, is generated that contains the protection class keys encrypted bythe user key and the unique device specific code.

In one aspect, when a user locks his device or the device automaticallyplaces itself in a locked state, the system 100 can grant certainapplications a grace period to finalize their data and write it to massstorage before enforcing the class encryption keys for a locked state.For example, if a user is composing an email on a mobile device andleaves mid-composition, the mobile device can automatically lock after atimeout duration. After the mobile device is locked, the system cangrant the email application a grace period and/or notify the emailapplication of the grace period duration so that the email applicationcan save the half composed email as a draft despite the mobile device'slocked state, for example.

A third key bag 730, the escrow key bag, contains all class encryptionkeys encrypted by the unique device specific code and a public key 210relating to an asymmetric key pair. The system 100 utilizes the escrowkey bag 730 during synchronization and/or backup operations. Lastly, thebackup key bag 740 contains all class encryption keys encrypted by thepublic key. The system uses the backup key bag 740 during a backupevent. It is important to note that the backup key bag 740 containsdifferent class encryption keys than the default, protected and escrowkey bags 710, 720, 730. In one variation, the backup and escrow key bags730, 740 are protected by the public key generated by the device, notthe user passcode. Because it may be impractical for a user to enter apasscode each time the system 100 performs a backup or synchronization,the system 100 can protect the protection class keys with a key thatdoes not relate to the user passcode. The backup host can store thebackup key bag.

Because the default key bag is not protected by a user passcode, thedevice is vulnerable to attack. For example, if an attacker steals thedevice and executes malicious computer code on it, he can access thedevice specific code and decrypt all class keys. Sensitive user data isno longer protected once an attacker decrypts the class keys because theattacker can decrypt all file encryption keys. The attacker can thendecrypt files with the file encryption keys, accessing sensitive userinformation. As stated above, one initial state of the device is toprotect class keys using the default key bag. When file-level dataprotection for the device is enabled, the system 100 uses the publicencryption key to protect the protected, escrow and backup key bags.

In one aspect, each class key is randomly generated. In another aspect,class keys in the default key bag are wrapped with the device's uniquedevice identifier (known as a UID or UDID), which is a unique codeassociated with the hardware of the device. The UID is only accessiblewhen the device is running in a secure environment and cannot be used byany other device. It should be noted that if the device is cracked suchthat the attacker can control the kernel, he can decrypt items protectedwith the UID. This is why one aspect of this disclosure is to alsoprotect key bags with a secret known only to the user.

Having discussed different protections for class encryption keys, thedisclosure now turns to the issue of backing up data from a devicehaving file-level data protection. FIG. 8 illustrates an exemplarybackup initiation method from a first device to a second device havingfile-level data protection from the perspective of the host device thatbacks up data from a client device. Before a backup can occur, the firstand second devices must initially establish a relationship. As part ofthe initial establishment of the relationship, the first device sends abackup secret to a second device (810), receives a backup ticketcontaining encryption keys from the second device (820) and stores thebackup ticket on the first device for later use in a backup event (830).In one aspect, the first and second devices are different, such as amobile device and a desktop computer. The devices can also be, forexample, a laptop backing up to a network-based backup service. Thefirst and second devices can be any pair of computing devices, at leastone of which has a file system that is at least partially encryptedusing file-level data protection. In one implementation, the backupsecret and backup ticket are stored separately. For example, the secretis chosen and stored on the client device and the backup ticket isstored on the host device.

FIG. 9 illustrates a second exemplary backup initiation methodembodiment from the perspective of a client device to be backed up by ahost device and FIG. 10 illustrates an exemplary backup initiationsystem configuration. The first device receives a backup secret 1010from a second device (910), creates a backup ticket 1020 containingencryption keys (920) and sends the backup ticket 1020 from the firstdevice to the second device (930) for later use in a backup event. Inone aspect, the device places itself in a lockdown state or the hostinstructs the device to place itself in a lockdown state. A lockdownstate can include suspending file operations, wireless transfers, filesystem reads and/or writes, user input, and so forth. Such a lockdownstate allows the data on the device to be backed up correctly andwithout interference or data corruption. Multiple lockdown states canexist which can apply to different hardware or software components andcan apply different levels of lockdown. For instance, one level oflockdown can allow read access to stored data but disallow write accessfor the duration of the backup process. In one lockdown state, user datais locked down but not operating system files. Other variations existand can be tailored to specific use cases or backup strategies.

FIG. 11 illustrates an example backup ticket 1110. In one variation, thebackup ticket 1110 includes a first backup secret encrypting the publickey, and a second backup secret encrypting the corresponding privatekey. The first device creates the backup ticket by encrypting anasymmetric encryption key pair containing a public key and a private keywith the backup secret provided by the second device. The system 100must decrypt the public key and the private key with the backup secretbefore using them in a backup event.

FIG. 12 illustrates a first exemplary backup method embodiment from theperspective of a client device having file-level data protection. Thefirst device receives a backup ticket containing encryption keysencrypted with a backup secret, and the backup secret from a seconddevice (1210), and retrieves an escrow key bag on the first device(1220). The escrow key bag contains protection class keys for theprotection classes encrypted with the public key and the unique devicespecific code. In one aspect, part of the escrow key bag is stored onthe first device and part is stored on the second device. The seconddevice can then combine the locally stored portion of the escrow key bagwith the retrieved portion of the escrow key bag received from the firstdevice to reconstitute the escrow key bag. The first device decrypts theprotection class keys with the backup ticket (1230) and generates abackup key bag containing new protection class keys (1240). The systemgenerates a backup key bag containing new protection class keys becausethe system sends the backup key bag to a backup device.

For security reasons, the original protection class keys never leave thedevice. Instead, this approach rewraps the individual files with a newset of class keys. When the host sends the backup ticket to the devicein order to access the original device class keys in the escrow key bag,the system can establish a new set of backup class keys. For enterpriseusers or other uses, the system can provide an option to disallow thenew set of class keys from being backed up. This can allow users tosupport a zero knowledge backup of the device to a host.

Once the system generates the backup key bag, the first device eitherautomatically selects or selects based on user input a set of encryptedfiles to back up (1250). The system 100 decrypts the file encryptionkeys corresponding to the selected set of encrypted files. The systemdecrypts the file encryption keys with the corresponding decryptedprotection class keys (1260) from the escrow key bag. The system 100re-encrypts the file encryption keys corresponding to the selected setof encrypted files with the new protection class keys (1270). In oneaspect, the system directly accesses encrypted data from the filesysteminstead of decrypting and re-encrypting the file encryption keys.

Once the system 100 re-encrypts the file encryption keys, they are readyfor transfer to the backup device. The first device transfers to thesecond device the selected set of encrypted files, the backup key bagand metadata associated with the selected set of encrypted files (1280),including the file encryption keys. It is important to note that thesystem stores the backup files along with the backup key bag, backupticket and backup secret on the backup device. Since the backup secretdecrypts the backup ticket, and the backup ticket decrypts the backupkey bag, the class protection keys are accessible. If the classprotection keys are accessible, then the backup file keys areaccessible, and the backup files can be decrypted. Since the backupclass protection keys differ from the class protection keys stored inthe default, protected and escrow key bags on a device, an attacker thataccesses backup keys can only decrypt backup files on the second device;he cannot access files on the first device. This approach can limit thepotential avenues an attacker can take to compromise sensitive user dataon a device.

FIG. 13 illustrates a second exemplary backup method embodiment from theperspective of a host device that backs up encrypted data from a clientdevice and FIG. 14 illustrates an exemplary backup system configuration.FIGS. 13 and 14 are discussed together below. The second device sends abackup ticket containing encryption keys encrypted with a backup secret,the backup secret 1410 and a host identifier to the first device (1310)and receives the selected set of encrypted files, the backup key bag andmetadata 1420 associated with the selected set of encrypted files fromthe first device (1320), including the file encryption keys.

Having disclosed backup initiation and the backup process on a systemwith file-level data protection, the disclosure now turns to restoringencrypted backup files to a device with file-level data protection. Inone aspect, encrypted backup files can be restored to a device notcapable or not configured to encrypt on a per-file and per-class basis.In this case, the restored backup files can retain their respectiveunique file keys and class keys which can be activated when the filesare restored to a device capable of such encryption.

In one backup variation, the host connects on the device to establish abackup relationship. The host generates a backup secret. If the user haschosen to protect his backups with a password, the secret can be derivedfrom this password. If not, the secret can be generated at random andstored on the host. The host sends this backup secret to the device. Thedevice creates a host identity if one does not already exist, andprovides it with the backup secret as well. The host constructs thebackup ticket based on a host identity and/or the backup secret andtransmits it to the device. Unlike a sync ticket, the two elements ofthe host identity are not encrypted with the device UID, but instead areencrypted with the backup secret. As a result, if the user has chosen toprotect his backups with a password, any backup content associated withthat backup ticket is essentially tied to the user's password. The hostcan store a key that can access files backed up from the device. Thismeans that an attacker could access data from a device if he has stolenor compromised the host. In some systems, availability of secure storagemitigates this risk, but other systems, such as Microsoft Windows®,options for such secure storage are limited.

FIG. 15 illustrates a first exemplary encrypted backup file restorationmethod embodiment from the point of view of a host device. The system100 sends a backup ticket, a backup secret, and a host identifier to afirst device having a file system encrypted on a per file and on a perclass basis (1510) and sends to the first device encrypted backup files,the backup key bag, and associated metadata including encrypted filekeys (1520). Since the protection class keys protecting the encryptedfile keys in the backup key bag differ from those in the default,protected and escrow key bags, the first device must re-encrypt the filekeys with the original class keys stored on the device. The first devicedecrypts the protection class keys in the backup key bag with the backupticket (1530) and decrypts the file encryption keys with thecorresponding decrypted protection class keys from the backup key bag(1540). Once the system decrypts the backup protection class keys andthe file encryption keys, the first device retrieves an escrow key bagcontaining original protection class keys (1550), re-encrypts thedecrypted file encryption keys with the original protection class keys(1560) and restores the encrypted backup files on the first device(1570).

FIG. 16 illustrates a second exemplary encrypted backup file restorationmethod embodiment for a client device and FIG. 17 an exemplary encryptedbackup file restoration file system configuration. FIGS. 16 and 17 arediscussed together below. The system 100 receives a backup ticket, abackup secret, and a host identifier at a first device (1610). Thesystem also receives encrypted backup files, the backup key bag andassociated metadata 1710 including encrypted file keys (1620) at thefirst device. The system decrypts the protection class keys in thebackup key bag with the backup ticket (1630) and decrypts the fileencryption keys with the corresponding decrypted protection class keysfrom the backup key bag (1640) on the first device. Once the devicedecrypts the protection class keys and the file encryption keys, thefirst device retrieves an escrow key bag containing original protectionclass keys (1650), re-encrypts the decrypted file encryption keys withthe original protection class keys (1660), and restores the encryptedbackup files based on the re-encrypted file keys on the first device(1670).

The disclosure now turns to a discussion of restoring a backup. Thesystem 100 can restore a backup to the same device that was the originalsource for the backup data or to another device. In either case, thebackup is based on the backup key bag. One example of this scenario isbacking up a mobile phone to a desktop computer and restoring the backedup data to the mobile phone, such as after a system erase and reinstall.When the host wants to restore a backup to the device, it needs to dotwo things. First, the host unlocks the device class keys, and alsoprovides the device with the backup class keys so that restored filescan be re-wrapped with the device class keys. The host can provide thebackup ticket and backup secret to unlock the escrow key bag as before.When the backup agent on the device restores a file from the host, itwill need to rewrap the file encryption key with the original deviceclass key. It receives the file's metadata from the host which includesthe wrapped file key. The system unwraps the wrapped key and decryptsthe file key using the appropriate backup class key, and then encryptsit with the appropriate device class key.

The backup agent then sets the metadata of the file with the rewrappedfile key. If the backup agent is restoring files from multiple backuprepositories, such as files that were backed up during an incrementalbackup, the host is responsible for sending the appropriate backup keybag to the device. In one aspect, the system can only load one backupkey bag at a time. This requires a certain level of coordination betweenthe backup component on the host and the agent on the device so that therewrapping operation does not fail or result in a corrupted file key.

The disclosure now turns to a discussion of restoring a backup to adifferent device with the backup key bag. One example of this scenariois backing up a mobile device to a desktop computer and restoring thebacked up data to a replacement device after the mobile device is lost,stolen, or destroyed. Restoring to a different device follows the exactsame mechanism as restoring to the original device with one importantdistinction: files that are associated with a protection class based ona device-specific identifier or UID. Files associated with a UID areprotected with the UID of the new device. One example of this is when adevice enrolls with a Virtual Private Network (VPN) server, the deviceis granted credentials that were only intended for that device, andshould not be allowed to migrate to another device, even in the eventthe original device was lost.

Having discussed the process of backing up a device with file-level dataprotection, the disclosure now turns to the issue of synchronizingdevices with file-level data protection.

FIG. 18 illustrates a first exemplary data synchronizationinitialization method embodiment for a host device. A first device sendsa host identifier and a pairing record to a second device havingfile-level data protection (1810). A pairing record can include a uniqueidentifier for the host which is known as the Host ID. The first devicethen receives from the second device a sync ticket containing encryptionkeys (1820) and stores the sync ticket on the first device (1830). Thesync ticket contains encryption keys that protect the protection classkeys. FIG. 19 illustrates a second exemplary data synchronizationinitialization method embodiment for a client device which iscomplementary to the exemplary method illustrated in FIG. 18. The system100 receives at a first device a host identifier and a paring recordfrom a second device (1910). The system 100 creates a sync ticketcontaining encryption keys based on the pairing record (1920). Thesystem 100 then sends the sync ticket to the second device.

FIG. 20 illustrates an example sync ticket. The sync ticket 2010encrypts a public key and a corresponding private key with the UID ordevice-specific code. The device to be synced creates the sync ticket byencrypting an asymmetric encryption key pair containing a public key anda private key with the host identifier and pairing record provided bythe second device. The system 100 must decrypt the public key and theprivate key in the sync ticket before it can use them in asynchronization event.

FIG. 21 illustrates a system initiating data synchronization. A firstdevice having a file system encrypted on a per file and on a per classbasis receives 2110 a host identifier and a pairing record from a seconddevice (1910), creates a sync ticket 2010 containing encryption keys(1920) and sends 2120 the sync ticket to the second device (1930).

FIG. 22 a first exemplary data synchronization method embodiment for ahost device. A first device sends a stored sync ticket to the seconddevice having file-level data protection (2210) and synchronizes datawith the second device based on at least one of the stored sync ticketand the decrypted protection class keys (2220). FIG. 23 illustrates asecond exemplary data synchronization method embodiment from theperspective of a client device. A first device having file-level dataprotection receives a sync ticket containing encryption keys from asecond device (2310) and retrieves an escrow key bag containingprotection class keys (2320). An escrow key bag can be used to unlock adevice during sync without the need for a user to enter a passcode. Theseparate secret is stored on host and device. This approach differs fromthe approach used with a system key bag, in that the escrow key bag isprotected by moving the secret off device. Escrow bags can be stored ona mobile device management server, for example, and used to reset thedevice from the mobile device management server.

The first device decrypts protection class keys based on the sync ticket(2330). The system decrypts the sync ticket with the unique devicespecific code stored on the device and decrypts the protection classkeys stored in the escrow key bag with the private key stored on thesync ticket. Once the system decrypts the protection class keys, thesystem can decrypt the file keys, and decrypt the files using thedecrypted file keys. Once the system decrypts the files, the system cansynchronize data with the second device (2340). This process allows fornew keys created between sync events to be escrowed by storing thepublic key of the sync ticket on the device. Additionally, the synceddevice may revoke access by removing escrowed keys from the device.

Having discussed synchronizing data between devices having file-leveldata protection, the disclosure now turns to the issue of obliteration.Obliteration is used to destroy or remove access to data on a device. Inone aspect, obliteration can include actually erasing data stored on adevice. In another aspect, obliteration does not actually erase datastored on a device, but removes the means for decrypting encrypted data,thereby effectively erasing data stored on the device by removing accessto the data in its usable clear form. In one implementation, a NANDflash layer includes an effaceable storage component which is utilizedto guarantee a key is deleted from the system during obliteration or apassword change. NAND flash is a type of non-volatile computer storage.

FIG. 24 illustrates one exemplary method embodiment outlining theprocess of obliteration. During the obliteration process a device withfile-level data protection destroys all key bags stored on the device(2410), such as keys or key bags stored in memory and key bags stored onmass storage such as a hard disk drive or solid-state drive. The system100 erases and rebuilds the file system (2420) and creates a new defaultkey bag (2430). The computing device 100 can then reboot to complete theobliteration process. In one aspect, the system 100 can performobliteration of another device or cause the device to performobliteration on itself, based on user input for example. In anotheraspect, the system 100 is a server that instructs, via a set of wirelesssignals such as cellular telephone signals or wifi signals, a remotedevice to perform obliteration on itself. A device can send aconfirmation to the server that verifies that the obliterationinstructions were successfully executed on the remote device. The devicecan send to the server incremental confirmations of each step in theobliteration process. One such scenario for this approach is erasing alost or stolen device containing confidential or sensitive informationwhen the device is still reachable via a wireless network.

When the system creates a new default key bag, it generates a new set ofprotection class keys and stores them in the default key bag. After thesystem obliterates the device, the device does not contain sensitiveuser information or does not have any way of accessing, understanding,or decrypting sensitive user information. Obliteration can be usefulwhen a device is refurbished for use by a different user.

In the variations discussed above, the device and host, whether backuphost or synchronization host, store different key bags. In one suitableconfiguration, the various key bags are stored as follows: the devicestores the backup key bag secret and the escrow key bag secret. The hoststores the backup key bag and the escrow key bag. The host canoptionally store the backup key bag secret.

Having discussed synchronizing data between devices having file-leveldata protection, the disclosure now turns to the issue of passcodeverification. Typically, a device stores a user passcode or somederivation of a user passcode, for example a hash. A hash is amathematical function that accepts a value as input and outputs a hashvalue. Often, the hash value is used as an array index. In the case whena device stores a passcode, the device compares an entered passcode withthe stored passcode on the device. If the passcodes match, a user isgranted access. In the case when a device stores a passcode hash, thedevice compares a hash of the entered passcode with the hash stored onthe device. If the hash values match, the user is granted access. Adevice with file-level data protection does not store the passcode orany derivation of the passcode on the device. For password verification,the device checks an entered passcode by attempting to decrypt dataencrypted with the passcode.

FIG. 25 illustrates an exemplary method for password verification on adevice having file-level data protection of at least a portion of itsfile system. A system 100 practicing the method decrypts, based on apassword, the class keys stored in the protected key bag with thepasscode (2510). The system 100 retrieves data from one or moreencrypted files using an encryption key from the decrypted key bag(2520). If the files decrypt correctly or match the decrypted datamatches expected data, the entered passcode is valid (2530). If thefiles do not decrypt correctly, the entered passcode is consideredinvalid and access is denied. In one aspect, the system 100 can“preheat” the profiled process that checks if a passcode is required tounlock the device (and to act as the go between for the UI to validatethe passcode) when waking up the device, to avoid delays for the user.Preheating can include one or more of loading the profiled process intomemory first when waking up the device, keeping the profiled processstored in memory even when in a locked or sleeping state, and/or otheroptimization approaches.

In one modification, the system performs garbage collection on keys tobe deprecated. The system can perform the garbage collection bycomparing a list of referenced counted class keys with a list of classkeys used in the file system, and removing keys which are not referencedor otherwise used. The system can also gradually or incrementallytransform wrapping keys when new keys are generated to protect newcontent.

The principles described herein can be applied in conjunction with othercompatible encryption approaches.

One configuration to which any or all of the principles described abovecan be applied is content protection. Content protection can include anyof a number of approaches to restrict reading and writing to protectedcontent, such as media files, system files, folders, keychains, filesystems, partitions, and individual blocks. In some cases, a firstportion of a file can be content protected while the remaining portionis unprotected. One specific example usage scenario is a mobile devicesuch as a smartphone. A mobile device can be easily lost or stolen, so auser can mitigate the risk to sensitive data stored on the mobile deviceby enabling content protection for the sensitive data, such as contacts,documents, calendar items, and so forth. Content can be protected basedon a user password, for example.

However, one problem with content protection based on a user password isthat user-entered passwords tend to be short. A password is only assecure as the amount of entropy, or uncertainty, the password has. Forexample, a four digit password has ten thousand possible combinations. Abrute force attack which simply tries every possible combination ofdigits can easily discover such a short password and compromise theprotected content, especially given the power, speed, and parallelprocessing available in modern computing devices. Longer passwords aredesirable due to the increased entropy, but users have difficultyremembering extremely long passwords.

One exemplary solution presented herein to this problem includes atleast two aspects. The first aspect is to combine a user password with alonger string, such as a secret, non-extractable, device-specific uniqueidentifier. The second aspect is to produce a derived cryptographic keyfrom the combined user password and the longer string through aniterative process that can only be performed on the device, such thatany brute force attack must step through each iteration and is thereforeslowed down. The system can then encrypt or otherwise protect contentwith the derived key.

In one example configuration, the device receives a user password. Theuser password can be a set of alphanumeric or other symbols, gestures,stylus input, biometric input, video input, image input, or anycombination thereof. The device then combines the user password with aunique, non-extractable code specific to the device to produce a derivedkey. For example, the device can make a system call passing the passwordas an argument, and the system call returns the derived key based on thenon-extractable device specific code. However, the device is unable todirectly access the device-specific code in software. The device canthen use that derived key to encrypt content on the device. Thisapproach can increase the required time to brute force attack encryptedcontent on the device.

In one aspect, the device-specific key in the hardware is roughly thesame strength as the key used to encrypt the data. For example, if thekey used to encrypt the data is a 256 bit key, the device-specific keycan be 256 bits, 128 bits, or 512 bits. The lengths of the keys can bewidely disparate as well, such as a 1024 bit device-specific key and a64 bit derived key for encrypting data. The device can use all or partof the device-specific key and all or part of the user password togenerate the derived key. For example, the device can generate thederived key from the entire user password and the first 100 bits of thedevice-specific key. The derived key can be larger than, smaller than,or the same size as the combination of the user password and thedevice-specific key.

One algorithm which can be used to produce the derived key is thepassword-based key derivation function version 2, or PBKDF2. PBKDF2takes a user password, a known value and the number of iterations toperform as input and produces a key. PBKDF2 in conjunction with thedisclosed algorithm produces the master key used for content encryption.

These approaches can limit the speed that an attacker can brute forcethe user password based on a function of the hardware to which thepassword is tied. Because the key is based on the non-extractable deviceidentifier, the maximum speed of any brute force attempt is limited tothe speed of the device itself. In many scenarios, such as smartphonesor other mobile devices, the relatively slow speed of the deviceseverely limits the brute force speed. Typically mobile deviceprocessors offer limited performance characteristics to fit within abattery envelope, but other devices such as a set-top box can alsopractice these principles. A powerful server-class computing device canalso practice the principles disclosed herein, but certain aspects maybe modified to increase the complexity of the operations and maintainsufficiently limited performance for potential brute force attacks. Forexample, the unique identifier in a server-class computing device can be4096 bits instead of 256, or the number of iterations can be 30,000,000instead of 50,000. Another approach for use with more powerful computingdevices, such as a desktop computer or a server, is to limit access tothe device specific key to a less powerful processor which is separatefrom the main processor.

In one implementation, the device takes the password and a known randomsalt, and runs one round, or iteration, of PBKDF2 using HMAC-SHA1(Hash-based Message Authentication Code—Secure Hash Algorithm 1) as thePRF (primitive recurse function). The number of rounds corresponds tothe number of 16-byte blocks the algorithm produces. FIG. 26 illustratesPBKDF2 using HMAC-SHA1. The device initializes the variables at thebeginning 2602 of the process. The variable i represents the currentround number, n represents the number of blocks and p represents theuser password. The variable t_(i) is block k represents the key, srepresents the salt value and u, is the HMAC-SHA1 output for block i.While i is not equal to the number of blocks minus one 2604, the firstiteration utilizes the user password and salt value to generate anintermediate value u_(i) from the HMAC-SHA1 algorithm. Subsequentiterations utilize the user password and the intermediate value u fromthe previous round, u_(i-1) 2606 to generate the intermediate valueu_(i). The variable t_(i) stores the exclusive-or (XOR) of all previousintermediate values, u_(i) 2608. The device generates the key byconcatenating each round block t, together 2610. Once the devicegenerates all blocks, the device outputs an intermediate key 2612.

FIG. 27 illustrates the master key generation process. The device takesthe resulting intermediate key 2612 from the PBKDF2 process and uses itas the value to fill an array of 16 byte AES blocks to be encrypted. Thedevice initializes the variables 2702 at the beginning of the process.The variable i represents the current round number, n the number ofblocks, b_(i) block i, k the master key value and h the non-extractabledevice-specific key. While i is not equal to the number of blocks minusone 2704, the device XORs the block number i into each block b_(i) 2706,such as by XORing into each word of each block. The device then encryptsthose blocks b_(i), using a non extractable device-specific, unique AESkey h 2708, and XORs the encrypted output of each block e_b_(i),together to produce the resulting master key, k 2710, 2712. The numberof iterations used for this operation is arbitrarily selectable. In onevariation, the device chooses a number that causes this entire operationto take around 50 milliseconds on the hardware available. In anothervariation, the user can indicate a desired security level whichcorresponds to a particular number of iterations. For example, if theuser selects “low security”, the device applies 10,000 iterations; ifthe user selects “medium security”, the device applies 50,000iterations; and if the user selects “high security”, the device applies200,000 iterations. The user can apply different security levels todifferent files, folders, or portions of a storage device. A flag orother indicator can signal to a protection mechanism how many iterationsto apply. Because these operations introduce a variable delay, with thehigher security having a longer delay, the user can decide how and whereto make the tradeoff between security and performance.

A larger number of iterations will produce a more secure password in thesense that a brute force attack will require more time to complete. Forexample, an iteration value of 100,000 may correspond to a 100millisecond delay, meaning that every turn in the brute force attackwould require 100 milliseconds. Further, because the device-specific keyis required, the speed of the device itself is a limiting factor and thebrute force attack cannot easily be parallelized or sped up beyond thecomputing capacity of the device. This approach increases the difficultyof a brute force attack by several orders of magnitude. One of the onlyways to speed up this attack is to physically disassemble and closelyexamine the chip in the device that stores the device-specific key.While PBKDF2 is discussed herein as one specific example, other suitablealgorithms can be applied as well, for example a cryptographic hashfunction or any other key derivation function. Any algorithm may be usedthat makes the derived key dependent on a serialized operation using adevice-specific or hardware-specific secret key which cannot be directlyextracted in software on the device.

The device can then use the derived master key to encrypt data on thedevice. The device can encrypt data block by block in an independentmanner as in electronic codebook (ECB) mode or in a doubly dependentchain of blocks as in cipher-block chaining mode (CBC). In ECB mode,data is divided into blocks and each block is encrypted independently ofother blocks. In cipher-block chaining mode, the ciphertext (encryptedblock) of a previous round is XOR'd with the plain text (unencryptedblock) of a next round. The resulting block is then encrypted. Anyencryption mode utilizing the derived master key is acceptable.

FIG. 28 illustrates a system utilizing a device-specific identifier anduser password to derive a cryptographic key. A user 2810 enters apassword or user PIN 2812 into a device 2802. The device CPU 2804retrieves a known salt value from storage 2808 and uses it along withthe entered password or pin 2812 and a non-recoverable, device-specificsecret identifier 2806 to generate a derived cryptographic key. In oneaspect, an accessor function or hardware module 2814 provides the CPUwith key generation results based on the device-specific identifier andthus provides only indirect access to the device-specific secretidentifier 2806.

FIG. 29 illustrates an exemplary block diagram 2900 of how to generate aderived, or combined, key. A user PIN 2902 such as a password orsequence of numbers to unlock a device is combined with a unique, devicespecific, secret identifier 2904 via an iterative key combiner 2906. Theiterative key combiner can be a hardware and/or software implementationof the PBKDF2 algorithm or some other suitable algorithm. The keycombiner yields a combined, or derived, key 2908 which the device thenuses to encrypt content on the device. In one aspect, the key can beused to encrypt content which is not stored on the device, but which isassociated with the device.

The disclosure now turns to the exemplary method embodiment shown inFIG. 30 for generating a cryptographic key. The method is discussed interms of a system, such as the system 100 shown in FIG. 1, configured topractice the method. The system 100 receives a user passcode on a device(3002). The device can be a mobile device, a personal computer, asmartphone, and so forth. Any device that has a non-extractable, uniquesecret can practice this method.

The system 100 combines at least part of the user passcode with at leastpart of a non-extractable secret associated with the device to yield aderived key (3004). The secret can be unique. In one aspect, each suchdevice has a unique secret from all other such devices. The system 100can combine the passcode and secret according to an encryption algorithmsuch as PBKDF2. PBKDF2 can be modified to accept or used in conjunctionwith an algorithm that accepts the device-specific secret in addition tothe passcode, the salt, and a number of iterations. PBKDF2 can produce aderived key that is longer or shorter than the sum of the passcode andthe non-extractable secret. For example, a passcode of any length and afixed size secret can always produce a fixed-length derived key, or thevariable length passcode and the fixed-size secret can produce avariable length derived key.

The system 100 encrypts content on the device with the derived key(3006). The content can be stored on a volatile or non-volatiles storagemedium, such as a hard drive, flash, memory, cache, and so forth.Individual blocks can be encrypted individually as in ECB mode or aspart of a double dependency chain of encrypted blocks, as in CBC mode.

Other principles disclosed herein can be applied to the derived orcombined key. For example, the derived key can be used as part of anencryption class key scheme, as part of one or more of a default keybag, a protected key bag, an escrow key bag, and a backup key bag, aspart of a backup secret or backup ticket, as part of a file key, as partof a sync ticket, and so forth. In one aspect, content protected byderived keys on one device can be migrated to another device having adifferent unique device specific identifier, such as when a userupgrades to a newer smartphone model, or when a PDA is lost and synceddata from the lost PDA is synced to a new PDA. The data to be migratedcan be converted into a clear or unprotected version of the data by useof the original device-specific secret, if it is available, or by use ofan escrow key bag or other similar approaches. Once the data is nolonger protected, a new or replacement device on to which the data isbeing migrated can reprotect the data with its own device-specificsecret.

One advantage of this approach is that user passwords can be short andstill retain highly secure attributes. A brute force attack on the keyderived from a user passcode in this way is algorithmically ratelimited, and limited even for attackers with access to significantcomputing power, because the device-specific key cannot be easilyextracted from the device, if at all.

One exemplary algorithm, illustrated in FIG. 31, is outlined below. Thisalgorithm calculates an AES key from the password. Given the user'spassword and a salt (which is randomly generated and stored in theclear), the system calculates K₁ by performing a single round of PBKDF2using HMAC_SHA1 as the PRF. This is equivalent to the following steps:

-   -   K₁=HMAC_SHA1(P, S ∥∥INT (1))∥∥HMAC_SHA1(P, S∥∥INT (2)) TRUNCATE        K₁ to 32 bytes

A new “tangle with hardware” operation performs i iterations of thefollowing step:

-   -   K_(n+1)=TANGLE_WITH_HARDWARE (K_(n,) i) where i is the desired        number of iterations

For every 128 iterations, the system encrypts one 4096 byte page whichstarts with K_(n) as the input and produces K_(n+1). The system fills a4096 byte buffer with a pattern of repeating K_(n) where each 4 byteword in K_(n) is XORed with the logical AES block number within the page(in little endian byte order) and put in the to-be-encrypted buffer.This 4 kilobyte buffer is then AES encrypted in CBC mode using the builtin hardware key. The IV used for the first CBC block is all 0. Afterencryption, the system XORs together K_(n), with each 32 byte regions inthe 4 kilobyte buffer to obtain a single 32 byte result K_(n+1).

The system continues repeating these steps until it reaches K_(n) wheren=i/128. If i is not divisible by 128, the last page will only prefilland encrypt and XOR one 32 byte block per remaining iteration. Theoutput is the AES key used to encrypt content in the system. The outputAES key is dependent on both the user's password and the device secret.By choosing an appropriate iteration count, the system rate limits howfast an attacker can attempt to brute force the users password to findthe resulting key.

FIG. 32 illustrates a second exemplary algorithm, outlined below. Thisalgorithm calculates an AES key from the password. Given the user'spassword and a salt (which is randomly generated and stored in theclear), the algorithm first calculates K₁ by performing a single roundof PBKDF2 using HMAC_SHA1 as the PRF. This is equivalent to thefollowing steps:

-   -   K=HMAC_SHA1(P, S ∥∥INT (1))∥∥HMAC_SHA1(P, S ∥∥INT (2)) TRUNCATE        K to 32 bytes

A new “tangle with hardware” operation calculates U₁ though U_(n), for agiven index n using the formula set forth below:

-   -   Pleft=first 16 bytes of K XORed with the value (2*n−1) in a        16-byte, big endian representation    -   Pright=last 16 bytes of K XORed with the value (2*n) in a        16-byte, big endian representation    -   P_(n)=Pleft followed by Pright    -   U_(n)=AES_EBC(HardwareKey, P_(n))

The resulting key R is obtained by XORing together U₁ though U_(n).These algorithms are exemplary. Other comparable algorithms can be usedand may be modified for optimization, speed, security, size, or otherconsiderations.

Embodiments within the scope of the present disclosure may also includetangible and/or non-transitory computer-readable storage media forcarrying or having computer-executable instructions or data structuresstored thereon. Such computer-readable storage media can be anyavailable media that can be accessed by a general purpose or specialpurpose computer, including the functional design of any special purposeprocessor as discussed above. By way of example, and not limitation,such computer-readable media can include RAM, ROM, EEPROM, CD-ROM orother optical disk storage, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to carry or storedesired program code means in the form of computer-executableinstructions, data structures, or processor chip design. Wheninformation is transferred or provided over a network or anothercommunications connection (either hardwired, wireless, or combinationthereof) to a computer, the computer properly views the connection as acomputer-readable medium. Thus, any such connection is properly termed acomputer-readable medium. Combinations of the above should also beincluded within the scope of the computer-readable media.

Computer-executable instructions include, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions. Computer-executable instructions also includeprogram modules that are executed by computers in stand-alone or networkenvironments. Generally, program modules include routines, programs,components, data structures, objects, and the functions inherent in thedesign of special-purpose processors, etc. that perform particular tasksor implement particular abstract data types. Computer-executableinstructions, associated data structures, and program modules representexamples of the program code means for executing steps of the methodsdisclosed herein. The particular sequence of such executableinstructions or associated data structures represents examples ofcorresponding acts for implementing the functions described in suchsteps.

Those of skill in the art will appreciate that other embodiments of thedisclosure may be practiced in network computing environments with manytypes of computer system configurations, including personal computers,hand-held devices, multi-processor systems, microprocessor-based orprogrammable consumer electronics, network PCs, minicomputers, mainframecomputers, and the like. Embodiments may also be practiced indistributed computing environments where tasks are performed by localand remote processing devices that are linked (either by hardwiredlinks, wireless links, or by a combination thereof) through acommunications network. In a distributed computing environment, programmodules may be located in both local and remote memory storage devices.

The various embodiments described above are provided by way ofillustration only and should not be construed to limit the scope of thedisclosure. The principles herein primarily discuss mobile devices, butcan be equally applied to any computing device. For example, a portablemass storage device can apply any or all of these approaches via itscontroller board when it interfaces with a laptop or desktop computer.Those skilled in the art will readily recognize various modificationsand changes that may be made to the principles described herein withoutfollowing the example embodiments and applications illustrated anddescribed herein, and without departing from the spirit and scope of thedisclosure.

1. A method for generating a master key for encrypting content stored bya computing device, the method comprising: at a hardware module includedin the computing device, wherein the hardware module is separate anddistinct from a processor included in the computing device: receiving,from the processor, a request to generate the master key, wherein therequest includes biometric data associated with a user of the computingdevice; accessing an identifier that is unique to the computing device,wherein the identifier is stored by the hardware module in a manner thatprevents software executing by way of the processor from directlyaccessing the identifier; combining the biometric data and theidentifier to produce a combined value; carrying out an iterativefunction on the combined value to produce the master key; and providingthe master key to the processor, wherein the master key is utilized bythe processor to encrypt the content.
 2. The method of claim 1, furthercomprising: receiving an indication of a desired security level for themaster key, wherein a number of iterations associated with the iterativefunction is based on the desired security level.
 3. The method of claim1, wherein the identifier is accessible only to the hardware modulewithin the computing device.
 4. The method of claim 1, wherein therequest specifies a number of iterations to be performed on the combinedvalue by the iterative function.
 5. The method of claim 4, wherein theiterative function includes a Password-Based Key Derivation Function 2(PBKDF2).
 6. The method of claim 4, wherein the iterative functionincludes a Hash-based Message Authentication Code Secure Hash Algorithm1 (HMAC-SHA1).
 7. The method of claim 1, wherein the identifier islarger in size than the biometric data.
 8. A non-transitory computerreadable storage medium configured to store instructions that, whenexecuted by a hardware module included in a computing device, cause thehardware module to generate a master key for encrypting content managedby the computing device, by carrying out steps that include: receiving,from a processor included in the computing device, a request to generatethe master key, wherein the request includes biometric data associatedwith a user of the computing device, and the processor is separate anddistinct from the hardware module; accessing an identifier that isunique to the computing device, wherein the identifier is stored by thehardware module in a manner that prevents software executing by way ofthe processor from directly accessing the identifier; combining thebiometric data and the identifier to produce a combined value; carryingout an iterative function on the combined value to produce the masterkey; and providing the master key to the processor, wherein the masterkey is utilized by the processor to encrypt the content.
 9. Thenon-transitory computer readable storage medium of claim 8, wherein thesteps further include: receiving an indication of a desired securitylevel for the master key, wherein a number of iterations associated withthe iterative function is based on the desired security level.
 10. Thenon-transitory computer readable storage medium of claim 8, wherein thesteps further include: providing the master key to the processor forencrypting content stored on the computing device.
 11. Thenon-transitory computer readable storage medium of claim 8, wherein theidentifier is accessible only to the hardware module within thecomputing device.
 12. The non-transitory computer readable storagemedium of claim 8, wherein the request specifies a number of iterationsto be performed on the combined value by the iterative function.
 13. Thenon-transitory computer readable storage medium of claim 12, wherein theiterative function includes a Password-Based Key Derivation Function 2(PBKDF2).
 14. The non-transitory computer readable storage medium ofclaim 12, wherein the iterative function includes a Hash-based MessageAuthentication Code Secure Hash Algorithm 1 (HMAC-SHA1).
 15. A computingdevice configured to generate a master key for encrypting content, thecomputing device comprising: a memory that stores the content; aprocessor, wherein the processor is configured to: receive a firstrequest to encrypt the content, wherein the first request includesbiometric data associated with a user of the computing device, andissuing, to a hardware module included in the computing device, a secondrequest to generate the master key based on the biometric data and anidentifier that is unique to the computing device, wherein theidentifier is stored by the hardware module in a manner that preventssoftware executing by way of the processor from directly accessing theidentifier; and the hardware module, wherein the hardware module isseparate and distinct from the processor and is configured to carry outsteps that include: receiving, from the processor, the second request,accessing the identifier stored by the hardware module, combining thebiometric data and the identifier to produce a combined value; carryingout an iterative function on the combined value to produce the masterkey; and providing the master key to the processor, wherein the masterkey is utilized by the processor to encrypt the content.
 16. Thecomputing device of claim 15, wherein the steps further include:receiving an indication of a desired security level for the master key,wherein a number of iterations associated with the iterative function isbased on the desired security level.
 17. The computing device of claim15, wherein: the hardware module is further configured to provide themaster key to the processor, and the processor is further configured toencrypt the content using the master key.
 18. The computing device ofclaim 15, wherein the hardware module is an only component included inthe computing device that is capable of accessing the identifier. 19.The computing device of claim 15, wherein the second request specifies anumber of iterations to be performed on the combined value by theiterative function comprises an iterative process that is performed onthe combined value.
 20. The computing device of claim 15, wherein theidentifier is larger in size than the biometric data.